home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.programming / comp.sys.amiga.programmer_30949_000016.msg < prev    next >
Encoding:
Text File  |  1994-11-27  |  3.3 KB  |  74 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: cs.chalmers.se!news.chalmers.se!sunic!pipex!bnr.co.uk!bnrgate!nott!torn!howland.reston.ans.net!darwin.sura.net!news-feed-1.peachnet.edu!concert!sas!mozart.unx.sas.com!walker
  3. From: walker@twix.unx.sas.com (Doug Walker)
  4. Subject: Re: Producer/Consumer model on Amiga
  5. Originator: walker@twix.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <C7AABB.GD5@unx.sas.com>
  8. Date: Wed, 19 May 1993 17:09:10 GMT
  9. References:  <C7A562.B1H@sparc0a.cs.uiuc.edu>
  10. Nntp-Posting-Host: twix.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 62
  13.  
  14.  
  15. In article <C7A562.B1H@sparc0a.cs.uiuc.edu>, maxwell@sparc0a.cs.uiuc.edu (Scott Maxwell) writes:
  16. |> I guess I'm wondering whether you always have to ReplyMsg() to _every_
  17. |> message you receive via GetMsg() (I always see this done, but I don't
  18. |> know whether it's actually necessary).
  19.  
  20. No, you don't need to do a ReplyMsg() as long as your second task
  21. knows how to dispose of the message.
  22.  
  23. Basically, a message is just a block of memory with some fields at
  24. the beginning that allow you to add it to linked lists (the linked
  25. lists are attached to the MsgPort you send it to.)  PutMsg takes your
  26. message and queues that memory block to the target MsgPort.  GetMsg
  27. removes it from that MsgPort and passes a pointer to it to you.
  28.  
  29. If AmigaDOS or Intuition sends you a message, you MUST REPLY TO IT.
  30. However, if you're simply talking to yourself, as in this case, you
  31. can really do whatever you want.
  32.  
  33. One example:
  34.  
  35.    1. Task B allocates MsgPortB using CreatePort(), giving the port a name
  36.    2. Task A uses FindPort() to find MsgPortB
  37.    3. Task A allocates MessageA using AllocMem()
  38.    4. Task A uses PutMsg() to send the MessageA to MsgPortB
  39.    5. Task B uses GetMsg() to receive the message
  40.    6. After using the message, task B uses FreeMem() to free it.
  41.    7. Go back to step 3 and repeat until done
  42.  
  43. This scenario works fine, but it has one drawback - if you send lots
  44. of messages, you're calling AllocMem and FreeMem a whole heck of a 
  45. lot.  Why do that when you've already got messages allocated?
  46. How about this instead:
  47.  
  48.    1. Task B allocates MsgPortB using CreatePort(), giving the port a name
  49.    2. Task A allocates MsgPortB using CreatePort(), it's nameless
  50.    3. Task A uses FindPort() to find MsgPortB
  51.    4. Task A calls GetMsg() on MsgPortA.
  52.      4a. If no message is available, Task A allocates one and
  53.          increments a count of allocated messages
  54.      4b. If a message is available, Task A uses it
  55.    5. Task A sets the mn_ReplyPort field to point to MsgPortA
  56.    5. Task A uses PutMsg to send the message
  57.    6. Task B uses GetMsg to receive it
  58.    7. After using the message, task B calls ReplyPort
  59.    8. Go back to step 4 and repeat until done
  60.    9. Until task A's message count is zero, do:
  61.       9a. Task A uses GetMsg on MsgPortA
  62.          9a1. If no message, do a WaitPort()
  63.          9a2. Otherwise free the message and decrement the message count
  64.  
  65. It's a little more complicated, but much more efficient.
  66.  
  67.  
  68. -- 
  69.   *****                    / walker@unx.sas.com
  70.  *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
  71.  *|. o.| ||                \ CompuServe: 71165,2274
  72.   | o  |//     
  73.   ====== 
  74. Any opinions expressed are mine, not those of SAS Institute, Inc.